1. Field of the Invention
Embodiments of the present invention relate to a technique of processing a value of label, in a controlling process of a Label Switched Path (LSP), using a Resource Reservation Protocol-Traffic Engineering (RSVP-TE) protocol.
2. Description of the Related Art
A Resource Reservation Protocol-Traffic Engineering (RSVP-TE) protocol may be a standard of which standardization is advancing in an Institution of Electronics and Telecommunication Engineers (IETF), and may be a protocol for managing designation/release of a Label Switched Path (LSP) of an optic layer in an Internet Protocol (IP) transmission scheme, an asynchronous transfer mode (ATM) transmission scheme, and Ethernet.
The LSP may have a label, that is, a value used for uniquely identifying and transmitting the LSP. As an object within the RSVP-TE protocol for assigning and managing the label of the LSP, a label object, a generalized label object, a suggested label object, an upstream label object, and the like have been suggested.
FIG. 1 illustrates an example of a method for controlling an LSP using an RSVP-TE protocol according to a conventional art.
Referring to FIG. 1, the label object and the generalized label object may be RSVP-TE objects for assigning a label of the LSP in a downstream direction from an ingress node to an egress node, and may be operated in a general procedure as illustrated in FIG. 1.
In operation 101, a management plane may request designation of an LSP from an ingress node (A) to an egress node (D).
In operation 102, the ingress node (A) may calculate a next hop for reaching the egress node (D) to thereby obtain information about a transit node (B). The ingress node (A) may generate an RSVP-TE Path message to transmit the transit node (B). In this instance, in operation 103, the ingress node (A) may add a label request or a generalized label request to the RSVP-TE Path message to thereby transmit information about a switching type, an encoding type, and a payload type of a requested LSP.
In operation 104, the transit node (B) may receive the RSVP-TE Path message, calculate a next hop for reaching the egress node (D), and generate a new RSVP-TE Path message to thereby transmit the generated RSVP-TE Path message to a transit node (C), that is, the calculated next hop, in operation 105. The above described operations performed in the transit node (B) may be performed in the transit node (C) in the same manner.
Finally, in operation 108, when the egress node (D) receives the RSVP-TE Path message, the egress node (D) may assign an LSP-1 of an acceptable label and being suitable for contents (switching type, encoding type, and payload type) of a label request or a generalized label request, which are requested by the transit node (C) in an interface with the transit node (C). Next, in operation 109, the egress node (D) may designate related information using label information of the assigned LSP-1, so that data is received in a forwarding table of a data plane of the egress node (D). Also, in operation 110, the egress node (D) may generate an RSVP-TE Resv message, and apply, to the generated RSVP-TE Resv message, a value (LSP-1) of the label assigned to the label object or the generalized label object to thereby transmit the RSVP-TE Resv message to the transit node (C).
In operation 111, the transit node (C) receiving the RSVP-TE Resv message may designate that data using a value of a corresponding label is transmitted to a forwarding table of a data plane of the transit node (C) in accordance with the applied value (LSP-1) of the label. Next, the transit node (C) may assign a value (LSP-2) of an available label in a connection interface with the transit node (B) of a previous node. Also, in operation 113, the transit node (C) may designate that the value (LSP-2) of the assigned label is received to a forwarding table of a data plane of the transmit node (C), and also designate that data received as the LSP-2 label is switched into the LSP-1 to be transmitted. In operations 114, the transit node (C) may apply, to the label object or generalized label object of the RSVP-TE Resv message, the value (LSP-2) of the assigned label to thereby transmit the value (LSP-2) to the transit node (B). In operations 115, 116, and 117, the transit node (B) may receive the RSVP-TE Resv message, and perform the same operations as the above described operations of the transit node (C).
In operation 119, the ingress node (A) may finally receive the RSVP-TE Resv message, and control forwarding information of a data plane of the ingress node (A), so that data of a user is transmitted to an interface with the transit node (B) through the LSP, using a value (LSP-3) of a label transmitted to the label object or the generalized label object.
In this manner, the label object or the generalized object may be operated such that a downstream node may be assigned to the label object or the generalized object in an interface unit in hop-by-hop among all nodes constituting a single LSP.
As for values of labels of these objects, in a process of designating an LSP from an ingress node to an egress node while passing through transit nodes, each node may assign, in a hop-by-hop unit, a value of the label to an interface up to a next node. Each node may assign a value of the label to an interface up to a next node since the value of the label is a unique value within an interface of each node, and is not required to be a unique to the entire network.
However, a value of a label for identifying an LSP and transmitting data in a data transmission technique such as an IEEE 802.1Qay Provider Backbone Bridging-Traffic Engineering (PBB-TE) may be a unique value in an End-to-End range, may be determined only by an ingress node or an egress node of the LSP, or may be determined by a management plane. Accordingly, there is a need for effectively transmitting, to transit nodes, a value of a label assigned by the ingress node, the egress node, or the management plane to thereby control the transmitted value, however, the above described objects may be available objects in hop-by-hop, failing to provide the above described function .
To overcome the above problem, a method using a label Explicit Route Object (ERO) sub-object included in an ERO may be currently used. This method may be performed such that an ingress node designates all transit nodes one by one, where an LSP passes through, as a value such as a label ERO intended to be used in each transit node, using the ERO.
FIG. 2 illustrates an example of a method of controlling an LSP using a PBB-TE protocol according to a prior art.
Referring to FIG. 2, the PBB-TE protocol may use the ERO to designate an LSP from an ingress node (A) to an egress node (D). To apply label information to the ERO, a strict type of LSP may be required, and thereby the ingress node (A) may be required to have a function of performing a full route calculation for the LSP prior to a signaling process, in operation 202. In operation 203, the ingress node (A) may generate the ERO when the full route calculation is performed, and may simultaneously describe a value of an identical label while describing each hop of the ERO. That is, as for description of a hop, Internet Protocol version 4 (IPv4) sub-object and Internet Protocol version 6 (IPv6) sub-object each designating a specific node, and an interface sub-object designating an interface within each node are described, and a value of a label intended to be used in each hop may be repeatedly described. The method of controlling the LSP of FIG. 2 may be similar to that in FIG. 1 and thus, detailed descriptions thereof will be omitted.
As illustrated in drawings, the method of controlling the LSP using the PBB-TE protocol may need to perform the full route calculation using a path calculation engine in interior or exterior before performing an RSVP-TE signaling. Also, the ERO may be received in a single IP packet due to a relatively small size of the ERO, however, this may be impossible when a number of nodes constituting the LSP increases. Also, applying of an identical value may be inefficient method.